Subject: Mapping messages to DLS Circuits

From: "Jim (J.) Cobban" <[email-masked]>
Date: Mon, 17 May 1993 14:48:00 +0000

I am unclear on some of the details of how the finite state machine is driven
during circuit establishment.

The finite state machine which is defined in RFC1434 is associated with a
specific circuit, as discussed in section 4.2.  But not all messages
exchanged between data link switches, or between data link switches and their
associated data link control interfaces carry a circuit identification.  For
example the CANUREACH message is shown in the figure on page 9 as carrying
only a data link ID.  This is certainly reasonable, since the sending switch
cannot know what circuit ID to place in the packet, that being assigned by
the receiver.  The receiver must make a decision as to which FSM to send
the message to based upon the data link ID.  I assume that the receiver

 1) creates a brand new FSM to process the CANUREACH message,
 2) performs the local contact process.  If that process fails, delete the
    FSM
 3) if the local contact process succeeds change state to CIRCUIT_PENDING
    (not shown on page 9) send the ICANREACH with the half-circuit ID
    of the created FSM.

For no obvious reason the sending DLS has overridden the DSAP provided by the
originating station to match the OSAP.  Why is that value for DSAP any more
appropriate than any other?  In order to behave like other SNA devices on the
destination ring, the switch should send the local TEST frame out with a DSAP
of 0 anyway.

The circuit establishment process as it is described in RFC1434, for a
typical SNA TRN implementation which sends a TEST with DSAP 0 and OSAP 4
would result in the creation of a circuit for DSAP 4 and OSAP 4.  If the
originating station then sends a SABME with that pair of SAPs everything is
fine because that results in a DLC_CONTACT input to a FSM in state
CIRCUIT_ESTABLISHED.  But what happens if the station decides that it wants a
second SNA connection, but decides to use its existing knowledge of the
source-route to the destination MAC, discovered by the TEST?  The station
then sends a SABME with OSAP 4 and DSAP 8?  This requires a new circuit but
we have not negotiated the circuit IDs.  There is no FSM to deliver this
message to!  Note that there is no change to my concern if the station
chooses to send an XID before the SNRM.

I know that these comments are somewhat incoherent, but I am having
difficulty in determining. with precision, exactly how messages are mapped to
circuits.  The document does not make this clear.  The document also does not
say what header fields are valid for various requests, nor what values are
inserted into header fields which are unknown to the sender.

RFC1434 as it stands is not the place to discuss the various DLC
implementations.  However it seems that there must be some document, or
appendix which discusses how some specific implementations of DLC map to the
DLC events which are inputs to the DLS FSM, and how DLC actions are mapped to
DLC frames.  One value of such an exploration is that you can ensure that
there is a valid mapping.  I am not certain, at present, that a DLC function
can map frames to DLC events without knowledge of the internal state of the
DLS circuit that the events are to be delivered to.